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This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 

Official Protocol Standards" (STD 1) for the standardization state 

and status of this protocol. Distribution of this memo is unlimited. 
Introduction 


The purpose of this memo is to propose an update to Internet RFC 2045 
to include a new primary content-type to be known as "model". RFC 
2045 [1] describes mechanisms for specifying and describing the 
format of Internet Message Bodies via content-type/subtype pairs. We 
believe that "model" defines a fundamental type of content with 
unique presentational, hardware, and processing aspects. Various 
subtypes of this primary type are immediately anticipated but will be 
covered under separate documents. 
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1. Overview 


This document will outline what a model is, show examples of models, 
and discuss the benefits of grouping models together. This document 
will not directly deal with the intended subtypes since those will be 
covered by their separate registrations. Some immediately expected 
subtypes are listed in section 7. 


This document is a discussion document for an agreed definition, 
intended eventually to form a standard accepted extension to RFC 
2045. We are also targeting developers of input/output filters, 
viewer software and hardware, those involved in MIME transport, and 
decoders. 


2. Definition of a model 


A model primary MIME type is an electronically exchangeable 
behavioral or physical representation within a given domain. Each 
subtype in the model structure has unique features, just as does each 
subtype in the other primary types. The important fact is that these 
various subtypes can be converted between each other with less loss 
of information then to that of other primary types. This fact groups 
these subtypes together into the model primary type. All of the 
expected subtypes have several features in common and that are unique 
to this primary type. 


To loosely summarize: models are multidimensional structures composed 
of one or more objects. If there are multiple objects then one 
object defines the arrangement/setting/relationship of the others. 
These objects all have calibrated coordinate systems but these 
systems need not be in the same units nor need they have the same 
dimensionality. In detail: 


1. have 3 or more dimensions which are bases of the system and 
form an orthogonal system (any orthogonal system is sufficient). 


This system is specifically defined in terms of an orthogonal 

set of basis functions [for a subspace of the L*2 function space] 
over a coordinate system of dimension 3 or more. Note that this 
does not preclude regular skewed systems, elliptical coordinates, 
different vector spaces, etc. 


2. contain a structural relationship between model elements. 
3. have scaling or calibration factors which are related to physical 
units (force, momentum, time, velocity, acceleration, size, etc.). 


Thus, an IGES file will specify a building of non-arbitrary size, 
computational meshes and VRML models will have real spatial/ 
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temporal units. This allows for differing elements to be combined 
non-arbitrarily. 


4. Models can be single objects or composed of a collection of 
objects. These normally independent objects are arranged 
in a master/slave scenario so that one object acts as the 
reference, or primary object, which defines how the other 
objects interrelate and behave. This allows for the creation 
of mathematical, physical, economic, behavioral, etc. models 
which typically are composed of different elements. The key is 
in the description: these types describe how something 
"behaves"; contrasted to typical data types which describe 
how something "is". 


The inclusion of this "collective" system works similar to the 
Email system’s multipart/related type which defines the actions 


of the individual parts. Further specification of the model/* 
subtypes utilizing these properties is left to the subtype 
authors. 


With these assumptions: 


a. the default dimensionality will be spatial and temporal (but 
any are allowed). 


b. it is presumed that models will contain underlying structure 
which may or may not be immediately available to the 
user. (fluid dynamics vector fields, electromagnetic 
propagation, interrelated IGES dimensional specifiers, VRML 
materials and operators, etc.) 


c. it is assumed that basis set conversion between model domains 
is lossless. The interpretation of the data may change but 
the specification will not. i.e. convert the model of the 
U.S.A. Gross Domestic Product into a VRML model and navigate 
it to explore the variances and interrelationships. The model 
has many dimensions but also "passages" and "corridors" 
linking different parts of it. A similar situation is true 
for meshes and CAD files. The key is identifying the basis set 
conversion which makes sense. 


d. models are grouped to assure LESS loss of information between 
the model subtypes than to subtypes of other primary 
types. (i.e. converting a chemical model into an image is 
more lossy than concerting it into a VRML model). 
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Items c and d above define the grouping for model similar to the way 
that "images" and "videos" are grouped together; to assure less loss 
of information. Obviously converting from a GIF image to a JPEG 
image looses less information than converting from a GIF image to an 
AU audio file. 


3. Consultation Mechanisms 


Before proposing a subtype for the model/* primary type, it is 
suggested that the subtype author examine the definition (above) of 
what a model/* is and the listing (below) of what a model/* is not. 
Additional consultations with the authors of the existing model/* 
subtypes is also suggested. 


Copies of RFCs are available on: 
ftp://ftp.isi.edu/in-notes/ 
Copies of Internet-Drafts are available on: 
ftp://ftp.ietf.org/internet-—drafts/ 
Similarly, the VRML discussion list has been archived as: 
http://vrml.wired.com/arch/ 


and discussions on the comp.mail.mime group may be of interest. 
Discussion digests for the existing model/* subtypes may be 
referenced in the respective documents. 


The mesh community presently has numerous different mesh geometries 
as part of different packages. Freely available libraries need to be 
advertised more than they have been in the past to spur the 
development of interoperable packages. It is hoped that by following 
the example of the VRML community and creating a freely available 
comprehensive library of input/output functions for meshes [11] that 
this problem will be alleviated for the mesh community. A freely 
available mesh viewer conforming to these standards is available now 
for various platforms. Consulations with the authors of the mesh 
system, 


http: //www-dsed.1llnl.gov/documents/tests/mesh.html 
will be beneficial. 
The IGES community has a suite of tests and conformance utilities to 


gauge the conformance to specifications and software authors are 
encouraged to seek those out from NIST [14]. 
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4. Encoding and Transport 


a. Unrecognized subtypes of model should at a minimum be treated 
as "application/octet-stream". Implementations may optionally 
elect to pass subtypes of model that they do not specifically 
recognize to a robust general-purpose model viewing 
application, if such an application is available. 


b. Different subtypes of model may be encoded as textual 
representations or as binary data. Unless noted in the 
subtype registration, subtypes of model should be assumed to 
contain binary data, implying a content encoding of base64 for 
email and binary transfer for ftp and http. 


c. The formal syntax for the subtypes of the model primary type 
should look like this: 


Media type name: model 
Media subtype name: XXXXXXXX 
Required parameters: none 
Optional parameters: dimensionality, state 
(see below) 
Encoding considerations: base64 encoding is recommended when 


transmitting model/* documents through 
MIME electronic mail. 

Security considerations: see section 5 below 

Published specification: This document. 
See Appendix B for references to some of 
the expected subtypes. 

Person and email address to contact for further information: 
Scott D. Nelson <nelson18@llnl.gov> 
7000 East Ave. 
Lawrence Livermore National Laboratory 
Livermore, CA 94550 


The optional parameters consist of starting conditions and variable 
values used as part of the subtypes. A base set is listed here for 
illustration purposes only and will be covered in detail as part of 
the respective subtypes: 


dimension := string ; a number indicating the number of dimensions. 


This is used as a "hint" in selecting 
applicable viewer programs. 
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state := string ; "static" or "dynamic". In "static", the 
observer may move about, thus effecting 
translations, rotations, pans, zooms, etc. 
but the data does not change. In "dynamic", 
the data itself is manipulated via 
skews, elongations, scales, etc. Note that 
time evolution is still a static operation 
since it is just a translation along one of 
the principal dimensions while the elongation 
of a cube or object deformation are dynamic 
operations. 


Note that this optional parameter list does not limit those 
specified by the various subtypes. 


d. The specific issues relating to the various subtypes are covered 
as part of the description of those specific subtypes. The 
following is an example of a typical MIME header used for mail 
transport purposes: 


To: you@some.org 

From: nelsonl8@llnl.gov 

Date: Fri, 30 Aug 96 13:33:19 -0700 

Content-Type: model/mesh; dimension="4"; state="static" 
Content-Transfer-Encoding: base64 

MIME-Version: 1.0 

Subject: model data file 


I1ZSTUwgVjJEUMCBhc2NpaQojIFRoaxMgZm1sZSB3YXMgIGdlbmVyY... 
byBDb21tdW5pY2F0aw9ucwo jJIGHOdHA6LyI3d3cuY2ZhhY28uY29tC... 
TyBlc2VkIGluIHJvb20gMTkyIChOZXNOIHJvb20pCiAgIAojJIFRvc... 


Security Considerations Section 


Note that the data files are "read-only" and do not contain file 
system modifiers or batch/macro commands. The transported data is 
not self-modifying but may contain interrelationships. The data 
files may however contain a "default view" which is added by the 
author at file creation time. This "default view" may manipulate 
viewer variables, default look angle, lighting, visualization 
options, etc. This visualization may also involve the computation of 
variables or values for display based on the given raw data. For 
motorized equipment, this may change the position from the hardware’s 
rest state to the object’s starting orientation. 
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The internal structure of the data files may direct agents to access 
additional data from the network (i.e. inclusions); the security 
limits of whom are not pre-supposed. Actions based on these 
inclusions are left to the security definitions of the inclusions. 
Further comments about the security considerations for the subtypes 
will be contained in each subtype’s registration. 


6. Authors’ Addresses 


S. D. Nelson 

Lawrence Livermore National Laboratory, 
7000 East Ave., L-153, 

Livermore CA 94550, USA. 

E-Mail: nelson18@llnl.gov 


C. Parks 

National Institute of Standards & Technology 
Bldg 220, Room B-344 

Gaithersburg, MD 20899, USA. 

E-Mail: parks@eeel.nist.gov 


Mitra 

WorldMaker 

1056 Noe 

San Francisco, CA 94114 
E-Mail: mitra@earth.path.net 


7. Expected subtypes 


Table 1 lists some of the expected model sub-type names. Suggested 3 
letter extensions are also provided for DOS compatibility but their 
need is hopefully diminished by the use of more robust operating 
systems on PC platforms. The "silo" extension is provided for 
backwards compatibility. Mesh has an extensive list of hints since 
the present variability is so great. In the future, the need for 
these hints will diminish since the files are self describing. This 
document is not registering these subtypes. They will be handled 
under separate documents. 


Nelson, et. al. Standards Track [Page 7] 


RFC 2077 Model Primary MIME Types January 1997 


Table 1. 
Primary/sub-type Suggested extension (s) Reference 
model/iges igs, iges [8] 
model/vrml wrl [9] 
model/mesh msh, mesh, silo [10] 


It is expected that model/mesh will also make use of a number of 
parameters which will help the end user determine the data type 
without examine the data. However, note that mesh files are self- 
describing. 


regulart+static, unstructedtstatic, unstructuredtdynamic, 
conformal+static, conformal+tdynamic, isoparametric+static, 
isoparametric+dynamic 


The sub-types listed above are some of the anticipated types that are 
already in use. Notice that the IGES type is already registered as 
"application/iges" and that RFC states that a more appropriate type 
is desired. Note that the author of "application/iges" is one of the 
authors of this "model" submission and application/iges will be re- 
registered as model/iges at the appropriate time. 


The VRML type is gaining wide acceptance and has numerous parallel 
development efforts for different platforms. These efforts are 
fueled by the release of the QvLib library for reading VRML files; 
without which the VRML effort would be less further along. This has 
allowed for a consistent data type and has by defacto established a 
set of standards. Further VRML efforts include interfaces to other 
kinds of hardware (beyond just visual displays) and it is proposed by 
those involved in the VRML effort to encompass more of the five 
senses. Unlike other kinds of "reality modeling" schemes, VRML is 
not proprietary to any one vendor and should experience similar 
growth as do other open standards. 


The mesh type is an offshoot of existing computational meshing 
efforts and, like VRML, builds on a freely available library set. 
Also like VRML, there are other proprietary meshing systems but there 
are converters which will convert from those closed systems to the 
mesh type. Meshes in general have an association feature so that the 
connectivity between nodes is maintained. It should be noted that 
most modern meshes are derived from CAD solids files. 
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8. Appendices 
8.1 Appendix A -- extraneous details about expected subtypes 
VRML Data Types 


The 3D modeling and CAD communities use a number of file formats to 
represent 3D models, these formats are widely used to exchange 
information, and full, or lossy, converters between the formats exist 
both independently and integrated into widely used applications. The 
VRML format is rapidly becoming a standard for the display of 3D 
information on the WWW. 


Mesh Data Types 


For many decades, finite element and finite difference time domain 
codes have generated mesh structures which attempt to use the 
physical geometry of the structures in connection with various 
physics packages to generate real world simulations of events 
including electromagnetic wave propagation, fluid dynamics, motor 
design, etc. The resulting output data is then post processed to 
examine the results in a variety of forms. This proposed mesh 
subtype will include both geometry and scalar/vector/tensor results 
data. An important point to note is that many modern meshes are 
generated from solids constructed using CAD packages. 


Motivation for mesh grew out of discussions with other communities 
about their design requirements. Many CAD or scene descriptions are 
composed of a small number of complex objects while computational 
meshes are composed of large numbers of simple objects. A 1,000,000 
element 3D mesh is small. A 100,000,000 element 3D structured mesh 
is large. Each object can also have an arbitrary amount of 
associated data and the mesh connectivity information is important in 
optimizing usage of the mesh. Also, the mesh itself is usually 
uninteresting but postprocessing packages may act on the underlying 
data or a computational engine may process the data as input. 


Meshes differ principally from other kinds of scenes in that meshes 
are composed of a large number of simple objects which may contain 
arbitrary non-spatial parameters, not all of whom need be visible, 
and who have an implicit connectivity and neighbor list. This latter 
point is the key feature of a mesh. It should be noted that most 
meshes are generated from CAD files however. The mesh type has 
association functions because the underlying physics was used to 
calculate the interaction (if you crash a car into a telephone pole, 


you get a crumpled car and a bent pole). Most interesting 
computational meshes are 4D with additional multidimensional results 
components. 
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IGES CAD Data Types 


(The following text, reproduced for reference purposes only, is from 
"U.S. Product Data Association and IGES/PDES Organization Reference 
Manual," June 1995; by permission.) 


IGES, the Initial Graphics Exchange Specification, defines a neutral 
data format that allows for the digital exchange of information among 
computer-aided design (CAD) systems. 


CAD systems are in use today in increasing numbers for applications 
in all phases of the design, analysis, and manufacture and testing of 
products. Since the designer may use one supplier’s system while the 
contractor and subcontractor may use other systems, there is a need 
to be able to exchange data digitally among all CAD systems. 


The databases of CAD systems from different vendors often represent 
the same CAD constructs differently. A circular arc on one system may 
be defined by a center point, its starting point and end point, while 
on another it is defined by its center, its diameter starting and 
ending angle. IGES enables the exchange of such data by providing, in 
the public domain, a neutral definition and format for the exchange 
of such data. 


Using IGES, the user can exchange product data models in the form of 
wireframe, surface, or solid representations as well as surface 
representations. Translators convert a vendor’s proprietary internal 
database format into the neutral IGES format and from the IGES format 
into another vendor’s internal database. The translators, called pre- 
and post-processors, are usually available from vendors as part of 
their product lines. 


Applications supported by IGES include traditional engineering 
drawings as well as models for analysis and/or various manufacturing 
functions. In addition to the general specification, IGES also 
includes application protocols in which the standard is interpreted 
to meet discipline specific requirements. 


IGES technology assumes that a person is available on the receiving 
end to interpret the meaning of the product model data. For instance, 
a person is needed to determine how many holes are in the part 
because the hole itself is not defined. It is represented in IGES by 
its component geometry and therefore, is indistinguishable from the 
circular edges of a rod. 


The IGES format has been registered with the Internet Assigned 


Numbers Authority (IANA) as a Multipurpose Internet Mail Extension 
(MIME) type "application/iges". The use of the message type/subtype 
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in Internet messages facilitates the uniform recognition of an IGES 
file for routing to a viewer or translator. 


Version 1.0 of the specification was adopted as an American National 
Standards (ANS Y14.26M-1981) in November of 1981. Versions 3.0 and 
4.0 of the specification have subsequently been approved by ANSI. The 
current version of IGES 5.2 was approved by ANSI under the new 
guidelines of the U.S. Product Data Association. Under these 
guidelines, the IGES/PDES Organization (IPO) became the accredited 
standards body for product data exchange standards. This latest 
standard is USPRO/IPO-100-1993. 
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[10] S.D. Nelson, "Registration of new Media Type model/mesh", 
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[11] "SILO User’s Guide", Lawrence Livermore National Laboratory, 
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8.3 Appendix C -- hardware 
Numerous kinds of hardware already exist which can process some of 


the expected model data types and are listed here for illustration 
purposes only: 


stereo glasses, 3D lithography machines, automated manufacturing 
systems, data gloves (with feedback), milling machines, 
aromascopes, treadmills. 
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8.4 Appendix D -- Examples 


This section contains a collection of various pointers to examples of 
what the model type encompasses: 


Example mesh model objects can be found on this mesh page: 
http: //www-dsed.1llnl.gov/documents/tests/mesh. html 


Various IGES compliant test objects: 
http://www.eeel.nist.gov/iges/specfigures/index.html 


VRML Test Suite: 
http://www.chaco.com/vrml/test/ 


An image of a model of a shipping cage crashing into the ground: 
http://www.llnl.gov/liv_comp/meiko/apps/dyna3d/cagefig2.gif 


An image of a 100,000,000 zone mesh: 
http: //www.1llnl.gov/liv_comp/meiko/apps/hardin/PMESH.gif 


A video of a seismic wave propagation through a computational mesh: 
http://www.1llnl.gov/liv_comp/meiko/apps/larsen/movie.mpg 
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